Hypervisor-Based Enterprise Endpoint Protection

ABSTRACT

Described systems and methods allow the detection and prevention of malware and/or malicious activity within a network comprising multiple client computer systems, such as an enterprise network with multiple endpoints. Each endpoint operates a hardware virtualization platform, including a hypervisor exposing a client virtual machine (VM) and a security VM. The security VM is configured to have exclusive use of the network adapter(s) of the respective endpoint, and to detect whether data traffic to/from the client VM comprises malware or is indicative of malicious behavior. Upon detecting malware/malicious behavior, the security VM may block access of the client VM to the network, thus preventing the spread of malware to other endpoints. The client system may further comprise a memory introspection engine configured to perform malware scanning of the client VM from the level of the hypervisor.

BACKGROUND

The invention relates to systems and methods for protecting computersystems from malware, and in particular to anti-malware systemsemploying hardware virtualization technology.

Malicious software, also known as malware, affects a great number ofcomputer systems worldwide. In its many forms such as computer viruses,worms, and rootkits, malware presents a serious risk to millions ofcomputer users, making them vulnerable to loss of data and sensitiveinformation, identity theft, and loss of productivity, among others.

Hardware virtualization technology allows the creation of simulatedcomputer environments commonly known as virtual machines, which behavein many ways as physical computer systems. In typical applications suchas server consolidation and infrastructure-as-a-service (IAAS), severalvirtual machines may run simultaneously on the same physical machine,sharing the hardware resources among them, thus reducing investment andoperating costs. Each virtual machine may run its own operating systemand/or software applications, separately from other virtual machines.Due to the steady proliferation of malware, each virtual machineoperating in such an environment potentially requires malwareprotection.

Enterprise networks are increasingly using hardware virtualizationtechnology, giving individual users access to computing resources fromany location on the network, while protecting corporate data andfacilitating network administration. In an exemplary application,instead of operating a computer system having a full-fledged operatingsystem and applications, each user may operate a thin client endpointacting as a terminal to a virtual machine running remotely on a centralcorporate location.

There is considerable interest in developing anti-malware solutions forhardware virtualization platforms, solutions which are robust, scalable,and adapted to any network configuration.

SUMMARY

According to one aspect, a client system comprises at least oneprocessor configured to operate a hypervisor, the hypervisor configuredto execute a client virtual machine (VM) and a security VM distinct fromthe client VM. The security VM is configurable by a centralized securitymanager executing on a remote server connected to the client system by anetwork, wherein the remote server is programmed to configure aplurality of client systems including the client system, and wherein thesecurity VM is configured to control a network adapter of the clientsystem according to a security policy received from the remote server.The security VM is further configured to receive a data unit from thenetwork adapter, the data unit comprising a header and a payload, thedata unit destined for the client VM; and in response to receiving thedata unit, to determine whether the data unit is malicious according toa content of the payload. The security VM is further configured, whenthe data unit is not malicious, to transmit the data unit to thehypervisor for transmission to the client VM, and when the data unit ismalicious, to send a security report to the remote server, the securityreport indicative of the maliciousness of the data unit, and to restrictaccess of the client VM to the network adapter according to the securitypolicy. The hypervisor is further configured, in response to receivingthe data unit from the security VM, to transmit the data unit to theclient VM. The hypervisor further comprises a memory introspectionengine configured to determine whether the client VM comprises malwareaccording to a content of a section of memory of the client VM, and inresponse, when the client VM comprises malware, to send a security alertto the security VM.

According to another aspect, a server system comprises at least oneprocessor programmed to remotely configure a plurality of clientsystems, wherein configuring a client system of the plurality of theclient systems comprises sending a security policy to the client system,and wherein the client system comprises at least one processorconfigured to operate a hypervisor. The hypervisor is configured toexecute a client virtual machine (VM) and a security VM distinct fromthe client VM, the security VM configured to control network adapter ofthe client system. The security VM is further configured to receive adata unit from the network adapter, the data unit comprising a headerand a payload, the data unit destined for the client VM, and in responseto receiving the data unit, to determine whether the data unit ismalicious according to a content of the payload. The security VM isfurther configured, when the data unit is not malicious, to transmit thedata unit to the hypervisor for transmission to the client VM, and whenthe data unit is malicious, to send a security report to the serversystem, the security report indicative of the maliciousness of the dataunit, and to restrict access of the client VM to the network adapteraccording to the security policy. The hypervisor is further configured,in response to receiving the data unit from the security VM, to transmitthe data unit to the client VM. The hypervisor further comprises amemory introspection engine configured to determine whether the clientVM comprises malware according to a content of a section of memory ofthe client VM, and in response, when the client VM comprises malware, tosend a security alert to the security VM.

According to another aspect, a method comprises employing at least oneprocessor of a client system to form a hypervisor configured to expose aclient virtual machine (VM) and a security VM distinct from the clientVM. The security VM is configured to control a network adapter of theclient system, the security VM configurable by a centralized securitymanager executing on a remote server connected to the client system by anetwork, wherein the remote server is programmed to configure aplurality of client systems including the client system, and whereinconfiguring the client system comprises the remote server sending asecurity policy to the client system. The method further comprisesemploying the security VM to receive a data unit from the networkadapter, the data unit comprising a header and a payload, the data unitdestined for the client VM; employing the security VM, in response toreceiving the data unit, to determine whether the data unit is maliciousaccording to a content of the payload; and in response, when the dataunit is not malicious, employing the security VM to transmit the dataunit to the hypervisor for transmission to the client VM, and when thedata unit is malicious, employing the security VM to send a securityreport to the remote server, the security report indicative of themaliciousness of the data unit, and to restrict access of the client VMto the network adapter according to the security policy. The methodfurther comprises employing the hypervisor, in response to receiving thedata unit from the security VM, to transmit the data unit to the clientVM. The hypervisor further comprises a memory introspection engineconfigured to determine whether the client VM comprises malwareaccording to a content of a section of memory of the client VM, and inresponse, when the client VM comprises malware, to send a security alertto the security VM.

According to another aspect, a method comprises employing at least oneprocessor of a server system to remotely configure a plurality of clientsystems connected to the server system by a network, wherein configuringa client system of the plurality of client systems comprises sending asecurity policy to the client system; and in response to configuring theplurality of client systems, employing at least one processor of theserver system to receive a security report from the client system. Theclient system comprises a hypervisor configured to execute a clientvirtual machine (VM) and a security VM distinct from the client VM. Thesecurity VM is configured to control a network adapter of the clientsystem and is further configured to receive a data unit from the networkadapter, the data unit comprising a header and a payload, the data unitdestined for the client VM; and in response to receiving the data unit,to determine whether the data unit is malicious according to a contentof the payload. The security VM is further configured, in response, whenthe data unit is not malicious, to transmit the data unit to thehypervisor for transmission to the client VM, and when the data unit ismalicious, to send the security report to the server system, thesecurity report indicative of the maliciousness of the data unit, and torestrict access of the client VM to the network adapter according to thesecurity policy. The hypervisor is further configured, in response toreceiving the data unit from the security VM, to transmit the data unitto the client VM. The hypervisor further comprises a memoryintrospection engine configured to determine whether the client VMcomprises malware according to a content of a section of memory of theclient VM, and in response, when the client VM comprises malware, tosend a security alert to the security VM.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and advantages of the present invention willbecome better understood upon reading the following detailed descriptionand upon reference to the drawings where:

FIG. 1 shows an exemplary diagram of an anti-malware system comprising aplurality of client systems and a security server, according to someembodiments of the present invention.

FIG. 2 illustrates an exemplary hardware configuration of a clientsystem, according to some embodiments of the present invention.

FIG. 3 shows an exemplary hypervisor executing on a client system andexposing a client virtual machine and a security virtual machine,according to some embodiments of the present invention.

FIG. 4-A illustrates an exemplary configuration of a security virtualmachine controlling at least one network adapter, according to someembodiments of the present invention.

FIG. 4-B illustrates an exemplary configuration of a client virtualmachine, according to some embodiments of the present invention.

FIG. 5 illustrates exemplary components of the hypervisor of FIG. 3,according to some embodiments of the present invention.

FIG. 6 shows exemplary components executing on the security server, aswell as exemplary data exchanges between the security server and clientsystems, according to some embodiments of the present invention.

FIG. 7 shows an exemplary sequence of steps executed by the antimalwaresystem of FIG. 1 to register a client system on the corporate network,according to some embodiments of the present invention.

FIG. 8 shows an exemplary transmission of a data unit between the clientvirtual machine and the network, according to some embodiments of thepresent invention.

FIG. 9-A shows an exemplary sequence of steps performed by the securityvirtual machine of FIG. 7 when receiving a data unit destined for theclient virtual machine, according to some embodiments of the presentinvention.

FIG. 9-B shows an exemplary sequence of steps performed by the securityvirtual machine when receiving a data unit from the client virtualmachine, according to some embodiments of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the following description, it is understood that all recitedconnections between structures can be direct operative connections orindirect operative connections through intermediary structures. A set ofelements includes one or more elements. Any recitation of an element isunderstood to refer to at least one element. A plurality of elementsincludes at least two elements. Unless otherwise required, any describedmethod steps need not be necessarily performed in a particularillustrated order. A first element (e.g. data) derived from a secondelement encompasses a first element equal to the second element, as wellas a first element generated by processing the second element andoptionally other data. Making a determination or decision according to aparameter encompasses making the determination or decision according tothe parameter and optionally according to other data. Unless otherwisespecified, an indicator of some quantity/data may be the quantity/dataitself, or an indicator different from the quantity/data itself. Unlessotherwise specified, a hash is an output of a hash function. Unlessotherwise specified, a hash function is a mathematical transformationmapping a sequence of symbols (e.g. characters, bits) into a number orbit string. Computer readable media encompass non-transitory media suchas magnetic, optic, and semiconductor storage media (e.g. hard drives,optical disks, flash memory, DRAM), as well as communications links suchas conductive cables and fiber optic links. According to someembodiments, the present invention provides, inter alia, computersystems comprising hardware (e.g. one or more processors) programmed toperform the methods described herein, as well as computer-readable mediaencoding instructions to perform the methods described herein.

The following description illustrates embodiments of the invention byway of example and not necessarily by way of limitation.

FIG. 1 shows an exemplary anti-malware system 10 according to someembodiments of the present invention. System 10 comprises a securityserver 12 and a plurality of client systems 16 a-d, all connected tonetworks 18 a-b. Some client systems, such as client systems 16 a-b inFIG. 1, may be physically located together, e.g. in an office building,and may be interconnected by a corporate network 18 a, which maycomprise a local area network (LAN).

Client systems 16 a-d may represent end-user devices such as computersand mobile telephones, among others, each having a processor, memory,and storage. In some embodiments, each client system 16 a-d may be usedby a single user (e.g., an employee of a company), or several users mayaccess the same client system 16 a-d (e.g. in work shifts, sales pointsoperated by multiple employees, etc.).

Some client systems, such as client systems 16 c-d in FIG. 1, may accesscorporate network 18 a remotely, e.g., from home or as a mobile client,and may do so via a wide area network (WAN) 18 b, such as the Internet.Network 18 a may operate in various degrees of isolation from network 18b, for example networks 18 a-b may be separated by a firewall. Dataexchanges between client systems 16 a-d and security server 12 may takeplace over networks 18 a-b, as shown in detail below.

FIG. 2 shows a hardware configuration of an exemplary client system 16,such as client systems 16 a-d in FIG. 1, according to some embodimentsof the present invention. System 16 represents a computer system forillustrative purposes; other client devices such as mobile telephones ortablets may have a different configuration. In some embodiments, system16 comprises a processor 20, a memory unit 22, a set of input devices24, a set of output devices 26, a set of storage devices 28, and atleast one network adapter 30, all connected by a set of buses 34.

In some embodiments, processor 20 comprises a physical device (e.g.multi-core integrated circuit) configured to execute computationaland/or logical operations with a set of signals and/or data. In someembodiments, such logical operations are delivered to processor 20 inthe form of a sequence of processor instructions (e.g. machine code orother type of software). Memory unit 22 may comprise volatilecomputer-readable media (e.g. RAM) storing data/signals accessed orgenerated by processor 20 in the course of carrying out instructions.Input devices 24 may include computer keyboards, mice, and microphones,among others, including the respective hardware interfaces and/oradapters allowing a user to introduce data and/or instructions intosystem 16. Output devices 26 may include display devices such asmonitors and speakers among others, as well as hardwareinterfaces/adapters such as graphic cards, allowing system 16 tocommunicate data to a user. In some embodiments, input devices 24 andoutput devices 26 may share a common piece of hardware, as in the caseof touch-screen devices. Storage devices 28 include computer-readablemedia enabling the non-volatile storage, reading, and writing ofsoftware instructions and/or data. Exemplary storage devices 28 includemagnetic and optical disks and flash memory devices, as well asremovable media such as CD and/or DVD disks and drives. A set of networkadapters 30 enables system 16 to connect to networks 18 a-b and/or toother devices/computer systems. Buses 34 collectively represent theplurality of system, peripheral, and chipset buses, and/or all othercircuitry enabling the inter-communication of devices 20-32 of clientsystem 16. For example, buses 34 may comprise the northbridge connectingprocessor 20 to memory 22, and/or the southbridge connecting processor20 to devices 24-30, among others.

FIG. 3 shows an illustrative software configuration of client system 16,according to some embodiments of the present invention. In someembodiments, a hypervisor 40 executes on the client system hardware.Hypervisor 40, also known in the art as a virtual machine monitor,comprises software allowing the multiplexing (sharing) by multiplevirtual machines of hardware resources of client system 16, such asprocessor operations, memory, storage, input/output, and networkingdevices. In some embodiments, hypervisor 40 enables multiple virtualmachines (VM) and/or operating systems (OS) to run concurrently onclient system 16, with various degrees of isolation. Virtual machinesare commonly known in the art as software emulations of actual physicalmachines/computer systems, each capable of running its own operatingsystem and software independently of other VMs. Examples of popularhypervisors include the VMware ESXi™ from VMware Inc. and theopen-source Xen hypervisor, among others.

Client system 16 further comprises a client VM 52 and a security VM 54,operating concurrently and exposed by hypervisor 40. While FIG. 3 showsjust two VMs for simplicity, client system 16 may include multiple VMs52, 54. The number of VMs may change during the operation of clientsystem 16. In some embodiments, each client VM may have an associatedsecurity VM. A single security VM may service multiple client VMsexecuting concurrently on client system 16. In some embodiments,security VM 54 is configured to execute as long as there is at least aclient VM operating on the respective client system. Hypervisor 40 maybe configured to prevent client VM 52 from using network adapter(s) 30when there is no security VM in operation.

In some embodiments, client VM 52 may execute a client operating system56 and/or a set of software applications 62 a-b concurrently andindependently of other VMs running on client system 16. OS 56 comprisessoftware that provides an interface to the (virtualized) hardware ofclient VM 52, and acts as a host for computing applications 62 a-brunning on the respective OS. Client OS 56 may comprise any widelyavailable operating system such as Windows®, MacOS®, Linux®, iOS®, orAndroid™, among others. Applications 62 a-b may include word processing,image processing, database, browser, and electronic communicationapplications, among others.

In some embodiments, a security agent 63 may execute on client OS 56concurrently with applications 62 a-b. Security agent 63 may beconfigured to interface with hypervisor 40, e.g. to receive from amemory introspection engine 46 executing within hypervisor 40 a securityalert indicative of the fact that client VM 52 is infected with malware.In another example, hypervisor 40 may alert security agent 63 whensecurity VM 54 determines (as shown below) that client VM 52 isconducting malicious transactions over network(s) 18 a-b. To receivesuch a security alert from hypervisor 40, security agent 63 may employany of a number of methods known in the art of virtualization. Forexample, hypervisor 40 may use an interrupt injection mechanism tonotify agent 63 to receive the alert. In some embodiments, uponreceiving communication from hypervisor 40, security agent 63 maydisplay a message on an output device of client system 16.

In some embodiments, security VM 54 is launched by hypervisor 40 from anauthenticated image stored on a computer-readable medium of clientsystem 16, as shown in more detail below. In other embodiments, securityVM 54 and/or hypervisor 40 are loaded from a secure location accessiblevia networks 18 a-b, for instance using a pre-boot execution environment(PXE). Security VM 54 may execute a security operating system 58providing a software interface to the (virtualized) hardware of securityVM 54. In some embodiments, security OS 58 comprises OS componentsenabling routing of data between security VM 54 and client VM 52, asdescribed below. OS 58 acts as a host for a network introspection engine60, an event correlation engine 68, and possibly other applications orservices. In some embodiments, security OS 58 may comprise a modifiedversion of a widely available operating system such as Linux® orAndroid™, among others. Network introspection engine 60 is configured tointercept and analyze data traffic between client VM 52 and network(s)18 a-b. Some parts of network introspection engine 60 may execute atuser privilege level, while other parts may execute at kernel privilegelevel. The operation of engine 60 is detailed below.

In some embodiments, event correlation engine 68 is configured toreceive data, such as security alerts, from network introspection engine60 and from memory introspection engine 46 executing within hypervisor40, and to combine such data to determine whether client VM 52 comprisesmalware and/or is conducting malicious network transactions. Upondetecting malware/malicious activity, some embodiments of correlationengine 68 may formulate a security report according to data receivedfrom introspection engines 46 and/or 60, and to send the report tosecurity server 12. To receive data from hypervisor 40, eventcorrelation engine 68 may be configured to access a section of memoryshared between engine 68 and hypervisor 40, or to use any other methodknown in the art of virtualization. For instance, hypervisor 40 may usean interrupt injection mechanism to notify event correlation engine 68to receive an alert.

In some embodiments, software forming part of hypervisor 40 creates aplurality of virtualized, i.e., software-emulated devices, eachvirtualized device emulating a physical device 20-34, and assigns a setof virtual devices to each VM operating on client system 16. Thus, eachVM 52, 54 operates as if it possesses its own set of physical devices,i.e., as a more or less complete computer system. In some embodiments,only a subset of hardware devices 20-34 is virtualized. Some hardwaredevices of client system 16 may be shared between virtual machines 52and 54. In the embodiment of FIG. 3, some devices such as input devices26 and output devices 28 of system 16 are used exclusively by client VM52, while other devices, such as network adapter(s) 30, are usedexclusively by security VM 54. Such partitioning of hardware betweenclient and security VMs may be preferable for reasons of security, asdiscussed further below.

FIGS. 4-A-B illustrate exemplary configurations of security VM 54 andclient VM 52, respectively, according to some embodiments of the presentinvention. VM 54 comprises a virtualized processor 120 and a virtualizedmemory unit 122, both connected by virtualized buses 134. Security VM 54is configured to control at least one of network adapter(s) 30. In someembodiments, controlling the respective network adapter comprisessecurity VM 54 having exclusive use of the respective adapter, e.g.,being capable of restricting access of client VM 52 to the respectiveadapter. Control of the respective network adapter by security VM 54 maybe enforced via hypervisor 40. Such a configuration may prevent clientVM 52 for using adapter(s) 30 for malicious purposes, as detailedfurther below. Also, in the embodiment of FIG. 4-A, security VM 54 isconfigured without explicit input and output devices. In someembodiments, when such devices are required for operation by security OS58, hypervisor 40 may present OS 58 with dummy input and/or outputdevices, wherein such dummy devices do not perform actual input and/oroutput operations. Configuring security VM 54 not to have access toinput and/or output devices of system 16 may prevent a malicious entity(e.g., a Trojan or a user with malicious intent) from modifying acontent of security VM 54 (e.g., by typing instructions into VM 54), orfrom viewing a content of security VM 54 by e.g., having VM 54 displaythe respective content on a screen.

In the embodiment of FIG. 4-B, client VM 52 comprises a virtualizedprocessor 220, a virtualized memory unit 222, and a set of virtualizednetwork adapters 130, while having exclusive use of input 24, output 26,and storage devices 28. Each virtualized network adapter 130 comprises asoftware emulation of a corresponding physical network adapter 30 ofclient system 16. In some embodiments, only a selected subset of networkadapters is virtualized. For instance, hypervisor 40 may set up anemulated hardware configuration wherein client VM 52 can accessnetwork(s) 18 a-b via a selected virtualized adapter 130.

Having hypervisor 40 present client OS 56 with emulated networkadapter(s) 130 may allow hypervisor 40 to control the network traffic toand from client VM 52, while allowing client OS 56 to operate as if VM52 possessed its own physical network adapter. For example, such aconfiguration may allow client VM 52 to execute an off-the-shelf versionof client OS 56 (e.g. Microsoft Windows®), without a need forcustomizing OS 56 to interface with hypervisor 40. To save ondevelopment costs, some embodiments may use a virtualized networkadapter, which represents a simplified device, without the fullfunctionality of physical network adapter(s) 30 of system 16.

FIG. 5 shows an exemplary diagram of hypervisor 40 according to someembodiments of the present invention. Hypervisor 40 comprises a hardwaremanager 42, a communication dispatcher 44 connected to the hardwaremanager, and a memory introspection engine 46. In some embodiments,hardware manager 42 is configured to determine which physical devices(e.g., network adapter(s) 30, etc.) are allocated to either security VM54 or client VM 52, and which devices need to be virtualized (e.g.,processor 20, memory 22, etc.). In some embodiments, hardware manager 42may identify a physical device according to the Peripheral ComponentInterconnect (PCI) device class of the respective device (e.g., 0x02 fornetwork interfaces), and/or according to a PCI vendor and device IDs(e.g., 0x8086 for “Intel, Inc”, 0x1076 for “Intel PRO/1000 MT ServerAdapter”).

Hardware manager 42 may be further configured to control and manageconfiguration parameters of certain devices of client system 16 duringoperation of VMs 52 and 54. Such parameters include, for each device ofclient system 16, input/output ports, memory mapped input/output (MMIO)zones, the PCI configuration space, interrupt requests (IRQ), andmessage-signaled interrupts (MSI), among others. For instance, hardwaremanager 42 may intercept attempts made by client OS 56 and/or securityOS 58 to modify certain device parameters, e.g., to allocate a new MMIOzone for a certain PCI device, and configure the respective virtualizeddevice accordingly.

In some embodiments, communication dispatcher 44 (FIG. 5) is configuredto manage the two-way transfer of data between client VM 52 and networkadapter(s) 30 of client system 16. Communication dispatcher 44 mayoversee transfer of data from VMs 52, 54 to hypervisor 40 and fromhypervisor 40 to VMs 52 and 54. The operation of dispatcher 44 will bedescribed in more detail below.

In some embodiments, memory introspection engine 46 is configured todetect malware within client VM 52 from the level of hypervisor 40.Several such anti-malware methods are known in the art ofvirtualization. For instance, engine 46 may intercept a processor eventsuch as a virtual machine exit event, transferring control of theprocessor from client VM 52 to hypervisor 40. Such events may betriggered for example when target software running within client VM 52attempts to execute a privileged instruction, requiring processor rootprivilege level (such as VMX root mode on Intel platforms). Byintercepting the VM exit event, hypervisor 40 may gain access to anaddress within the memory space of client VM 52, the memory spacecontaining code of the target software currently being executed. Bysubsequently translating the address into an address within a memoryspace of hypervisor 40 (using, e.g, page tables maintained by client OS56 and/or hypervisor 40), hypervisor 40 may have access to a content ofa section of physical memory identified by the respective address andcorresponding to target software. This respective section of memory maythen be scanned for malware, e.g., to detect malware-identifyingsignatures.

Alternatively, memory introspection engine 46 may detect malware withinclient VM 52 by detecting an attempt by target software to modify acontent of a protected memory region of VM 52. When client OS 56 is aLinux operating system, exemplary protected memory regions include: thekernel (read-only code and/or data such as sys_call_table),sysenter/syscall control registers, addresses int 0x80 (syscall) and/orint 0x01, among others. Exemplary protected regions on a Windows clientOS 56 include: the kernel (read-only code and/or data, including theSystem Service Dispatch Table), various descriptor tables (e.g.,interrupt, general and/or local), sysenter/syscall control registersand/or other registers such as an interrupt descriptor table register(IDTR), a global descriptor table register (GDTR), and a localdescriptor table register (LDTR).

Memory introspection engine 46 may run part of the security scanning asa background process, and may be configured to perform anti-malwareoperations according to a time schedule (e.g., check the integrity ofvarious kernel modules of client OS 54 every few seconds), or accordingto a set of heuristic rules (e.g., whenever a process is launched, or aspecific driver is used, or a privileged instruction is executed). Insome embodiments, engine 46 is configured, upon determining that clientVM 52 comprises malware, to send a security alert to security agent 63executing within client VM 52 and/or to event correlation engine 68executing within security VM 54, which in turn can re-transmit thesecurity alert onto security server 12. Sending such alerts from thelevel of hypervisor 40 to the level of VM's 52, 54 may be done e.g., viaan interrupt injection mechanism.

FIG. 6 shows a set of exemplary components executing on security server12 (FIG. 1), as well as an exemplary data exchange between the securityserver and exemplary client systems 16 e-f, according to someembodiments of the present invention. Systems 16 e-f may represent anyclient system, such as client systems 16 a-d in FIG. 1. System 16 e maybe distinct from system 16 f, or systems 16 e and 16 f may bothrepresent the same client system. In some embodiments, server 12comprises a centralized security manager 48, an update manager 45, awarning manager 47, and a client policy database 50, all connected tosecurity manager 48. Security manager 48 configures security VMsexecuting on each client system from a central location on network(s) 18a-b. In some embodiments, configuring security VM 54 of client system 16e (FIG. 6) comprises sending a security policy 66 to client system 16 eover network(s) 18 a-b and receiving a security report 64 from therespective client system. Some policies 66 may be issued in response toreceiving security reports from the respective client systems; otherpolicies 66 may be causally unrelated to security reports. Configuringsystem 16 e may further include performing a remote attestation ofclient system 16 e, as shown below.

In some embodiments, security policy 66 comprises a set of parametervalues configuring the operation of security VM 54 in variety ofcircumstances. Security policy 66 may include an indicator of aprocedure to be performed by security VM 54 when VM 54 detects maliciousnetwork traffic at adapter(s) 30 and/or when memory introspection engine46 determines that client VM 52 comprises malware. In some embodiments,policy 66 may specify a level of access of client VM 52 to networkadapter(s) 30. Each network adapter 30 of client system 16 e may becovered by a distinct policy 66, or all adapters 30 may operateaccording to a common policy. For instance, policy 66 may instructsecurity VM 54 to block all network traffic to and/or from client VM 52when client VM 52 comprises malware, or when network introspectionengine 60 intercepts a malicious network packet. In some embodiments,policy 66 may include a set of network addresses, and a set ofaddress-specific access levels. Such an exemplary policy 66 may allowclient VM 52 to access certain network addresses (e.g., Internet sites),but may restrict VM 52 from connecting to another client system onnetwork(s) 18 a-b. Policy 66 may change during the operation of securityVM 54, as instructed by server 12.

In some embodiments, security server 12 maintains a record ofclient-specific security policies 66 in the form of client policydatabase 50. Server 12 may also store a plurality of security reports 64received from various clients over network(s) 18 a-b. Exemplary clientsystem 16 e, for instance via its event correlation engine 68, may issuesecurity report 64 and may send report 64 to server 12 following asecurity incident, for instance in response to its network introspectionengine 60 intercepting malicious network traffic. Security report 64 mayinclude an identifier of client system 16 e (e.g., IP address), atimestamp of the incident, and/or an indicator of a type of incident(e.g, malicious network traffic, malformed packet, alert from memoryintrospection engine 46, etc.). In some embodiments, when the securityincident involves malware executing on client VM 52, report 64 maycomprise an indicator of a type of malware detected by engine 46 (e.g.,virus, rootkit, etc.), and/or various information, such as copies ofsuspicious files, memory dumps, information about CPU execution context,network packet dumps, etc., information that can be used to analyze thesecurity incident in more detail.

In some embodiments, security manager 48 analyzes security reports 64coming from a plurality of client systems, and determines whether tochange a set of security policies currently enforced on the respectiveclient systems. When changes are operated to the respective policies,security manager 48 then sends updated policies 66 to the respectiveclients. Policy updates may affect not only the client system where aparticular report originated, but occasionally also other clientsystems. For instance, when malware is detected on a particular clientsystem, security manager 48 may decide to block access of the client VMexecuting on the respective client system to the network, but also toblock other client systems on network(s) 18 a-b from connecting to therespective client system. In such a case, security manager 48 will issuemultiple security policies 66 and distribute them to multiple clientsystems. Such measures by manager 48 may prevent the spread of malwareto other clients or servers connected to network(s) 18 a-b.

In some embodiments, warning manager 47 is configured to inform a systemadministrator about security incidents occurring on client systems, suchas client system 16 e in FIG. 6. Informing the administrator may includedisplaying incident data on an output device such as a computer screenconnected to server 12 and/or sending a security warning 69 to theadministrator by other means, such as email and SMS, among others.Operation of warning manager 47 may be triggered by security manager 48receiving security report 64.

In some embodiments, update manager 45 of security server 12 managessoftware updates and delivers such updates to client systems. A softwareupdate 67 (FIG. 6) may include anti-malware engine components (binaries)such as updated components of hypervisor 40 or of introspection engines46, 60, as well as engine parameters such as updated malware signaturesand/or behavior patterns, among others. Such updates may be retrievedfrom a remote software distribution server 14 over networks 18 a-b, anddelivered to client systems, such as client system 16 f in FIG. 6,according to a schedule, or whenever they become available. Distributionserver 14 may be maintained independently, by a security softwaredeveloper such as the provider of software for hypervisor 40, securityVM 54 and/or security server 12. In some embodiments, retrieval ofsoftware updates may be triggered by certain security incidents detectedon client systems configured by security server 12.

Some embodiments of security server 12 may use the mechanism of softwareupdates described above to perform pro-active malware scanning of clientsystems 16 a-d. For example, when certain malicious actions are observedon a client system, a history of network activity and/or OS activity ofthe respective client may be gathered by components of security VM 54executing on the respective client system and sent to server 12. Inresponse to receiving such information, server 12 may analyze thehistory to construct a set of heuristic rules regarding network and/orOS behavior, rules which can be applied for early detection of maliciousbehavior on other clients. The new set of malware-detecting rules may bepackaged as a software and/or policy update and delivered to clientsystems 16 a-d. Some embodiments of server 12 may be further configuredto communicate information about security incidents occurring on clientsystems 16 a-d to a security software developer, e.g., via server 14.For instance, security server 12 may send data gathered from securityreports 64, such as copies of files and/or network activity patterns toserver 14, for detailed analysis. Such communication may facilitate thedetection of emerging malware threats, and the rapid development ofappropriate countermeasures.

FIG. 7 shows an exemplary sequence of steps performed by anti-malwaresystem 10 (FIG. 1) to initialize exemplary client system 16 and toregister client system 16 on networks 18 a-b. In a step 202, clientsystem 16 performs a trusted boot of security VM 54. In someembodiments, a trusted boot includes launching hypervisor 40 as well.Hypervisor 40 may form a part of an anti-malware package comprisingseveral software modules. Such anti-malware software may be installed ona client system already running a widely available OS such as Windows®,Linux® or iOS®. Hypervisor 40 takes control of processor 20 at rootprivilege level (e.g., VMXroot on Intel platforms), and displaces otherprocesses, including the OS, to non-root privilege level, thus creatinga hardware virtualization platform such as the one depicted in FIG. 3.Following the launch of hypervisor 40, any OS executing on client system16 prior to such installation becomes client OS 56, executing within thevirtual environment of client VM 52. Hardware manager 42 sets up andmanages virtualized hardware devices (e.g., FIG. 4-B) so client VM 52may operate as if it were running directly on the physical hardware ofsystem 16.

In some embodiments, performing a trusted boot of security VM 54includes ensuring that system 16 loads a trusted image of VM 54, forinstance an image that hasn't been tampered with (e.g., does notcomprise malicious code). Several such techniques are known in the art.For instance, step 202 may include loading security VM 54 from an imagefile stored on computer-readable media used by system 16. Alternatively,the image file may be stored in a secure location accessible overnetworks 18 a-b. The image file comprises a set of data representing amachine state of security VM 54. Before loading the image file ontomemory, hypervisor 40 may compute a hash of the image file and comparethe hash to a reference hash stored in a protected location of system16, such as a trusted platform module (TPM) chip. When the hash of theimage file matches the reference hash, indicating that the image file isauthentic, hypervisor 40 launches trusted VM 54 by loading the imagefile into memory, to be executed by processor 20. Computing the hash maycomprise applying a hash function to the image, or to a part of theimage; exemplary hash functions include checksum, cyclic redundancycheck (e.g., CRC32), and various cryptographic hash functions such asmessage-digest algorithms (e.g., MD5) and secure hash algorithms (e.g.,SHA256). The reference hash is computed by applying the same algorithmon a certified version of security VM 54.

In a step 204, client system 16 engages in a remote attestation ofsecurity VM 54 with security server 12. In some embodiments, remoteattestation comprises a set of operations executed by server 12 todetermine whether client system 16 operates a certified version of VM54, i.e., that the integrity of VM 54 has not been compromised bymalware executing on system 16. In an exemplary attestation process,system 16 sends a copy of the hash computed in step 202 to server 12,together with possibly other data such as login credentials of a user ofsystem 16, among others. Such data may be cryptographically signed witha unique secure key, such as the endorsement key of the TPM storing thereference hash, or a key provided by sever 12, or a key provided by athird party such as a certification authority. Upon receiving the data,server 12 may compare the hash received from client system 16 to areference hash stored on server 12. A hash match indicates thathypervisor 40 and/or VM 54 executing on the respective client system arein a trustworthy state (e.g., unaffected by malware), and thereforeattestation of client system 16 is successful. To perform suchattestation operations, some embodiments of server 12 maintain adatabase of trusted hashes, such as hashes of security VM images invarious configurations. Such hashes may be updated every time therespective VM images are updated.

In a step 206, security server 12 determines whether attestation ofclient 16 succeeded, and if no, proceeds to a step 210. When attestationwas successful, in a step 208, server 12 registers client system 16 onnetwork(s) 18 a-b and applies normal network operation policy to clientsystem 16. An exemplary normal network operation policy instructssecurity VM 54 of client system 16 to allow client VM 52 unrestrictedaccess to network(s) 18 a-b. When attestation did not succeed, in step210, server 12 registers a security event indicating that client system16 may be in an untrustworthy state, and in a step 212 applies a networkisolation policy to client 16. Such network isolation policies mayprevent the spread of malware on network(s) 18 a-b.

An exemplary network isolation policy applied to client system 16instructs clients distinct from client system 16 to reject networkconnection requests from system 16 and/or not to initiate networkconnections to client system 16. Such a policy may be implemented as aresult of a failed attestation of system 16, by e.g. security server 12sending policy updates to the respective client systems over network(s)18 a-b. In some embodiments, client systems distinct from client system16 interrogate security server 12 before connecting to client system 16to determine whether client system 16 is trusted; if client system 16 isnot trusted, security server 12 responds negatively to such queries. Inother embodiments, security server 12 may instruct other networkentities, such as a Dynamic Host Configuration Protocol (DHCP) serverand/or a router controlling the operation of network(s) 18 a-b torestrict network access to/from the unattested client system.

Following successful attestation of client system 16, two-way exchangesof data between client system 16 and network(s) 18 a-b may proceedaccording to a mechanism illustrated in FIG. 8. In typical digitalcommunication protocols, data circulating between two network entitiesis segmented into data units, such as data packets. Each data unit maycomprise a header and a payload, the header including administrativeinformation such as network routing addresses, and the payloadcomprising a fragment of the data itself. The size, formatting, and/orsemantics of data units may be protocol-specific. In some embodiments,data traffic entering and/or exiting client VM 52 is routed byhypervisor 40 via security VM 54, with network introspection engine 60analyzing said data for indicators of malicious activity or intent.Since security VM 54 is configured to have exclusive use of networkadapter(s) 30, VM 54 may effectively control network traffic enteringand/or exiting client VM 52.

When operating in send mode, an exemplary client VM 52 may use a networkdriver 72 a of client OS 56 to send a data unit 80 via to at least oneof virtualized network adapter(s) 130 configured and controlled byhypervisor 40. Communication dispatcher 44 of hypervisor 40 then picksup data unit 80 at adapter(s) 130 and forwards data unit 80 to networkintrospection engine 60 operating within security VM 54. After analyzingdata unit 80 and determining that data unit 80 is not indicative ofmalware, engine 60 may send data unit 80 to a network driver 72 b, whichmay be a component of security OS 58. Driver 72 b then employs at leastone of network adapter(s) 30 to transmit data unit 80 over network(s) 18a-b.

To transfer data unit 80 from hypervisor 40 to security VM 54, someembodiments of the present invention use an interrupt injectionmechanism to notify network introspection engine 60 of VM 54, e.g.through a dedicated software module, that data is available for sendingover network(s) 18 a-b. Several such interrupt injection techniques areknown in the art of virtualization; they represent a subclass ofvectored-event injection mechanisms, which inject processor events intoa virtual machine when transferring control of the processor from ahypervisor to a virtual machine controlled by said hypervisor (in thepresent example, from hypervisor 40 onto security VM 54).

In an exemplary receiving mode, security VM 54 receives data unit 80from the network via at least one of network adapter(s) 30 and networkdriver 72 b. Having exclusive use of adapter(s) 30, VM 54 may receivenetwork traffic destined for client VM 52, but also traffic destined forVM 54, such as security policies 66 sent by security server 12. Afterdetermining that data unit 80 is destined for client system 52, softwarecomponents of security VM 54 may forward data unit 80 to networkintrospection engine 60 for analysis. When data unit 80 is notindicative of malware, engine 60 may make data unit 80 available tohypervisor 40. Next, communication dispatcher 44 of hypervisor 40forwards unit 80 to a respective virtual network adapter 130 of VM 52.Network driver 72 a may then forward data 80 unit to its destination,e.g., a web browsing application executing in client OS 56.

To send data unit 80 from security VM 54 to hypervisor 40, asillustrated in FIG. 8, some embodiments of the present invention employinterception by hypervisor 40 of VM exit processor events, as describedabove in relation to the operation of memory introspection engine 46.For instance, engine 60 and/or other components of security VM 54 mayinclude instructions (such as VMCall and/or VMFunc on Intel platforms)which transfer control of the processor to hypervisor 40, calling onhypervisor 40 to receive data unit 80 from security VM 54. In someembodiments, data unit 80 is transferred from VM 54 to hypervisor 40through memory pages shared by VM 54 and hypervisor 40.

FIGS. 9-A-B show exemplary sequences of steps carried out by networkintrospection engine 60 according to some embodiments of the presentinvention. Engine 60 is configured to determine whether data trafficbetween client VM 52 and network(s) 18 a-b comprises malware and/orwhether such data traffic is indicative of malicious behavior. Inaddition, engine 60 may enforce a security policy as instructed bysecurity server 12, e.g., restricting data traffic to and/or from clientVM 52 upon detecting malware and/or malicious behavior.

FIG. 9-A illustrates the operation of engine 60 when intercepting datacirculating from the network to client VM 52, according to someembodiments of the present invention. In a step 222, networkintrospection engine 60 receives data unit 80 destined for client VM 52from at least one of adapter(s) 30, e.g. via network driver 72 b ofsecurity OS 58. In some embodiments, step 222 includes reconstructing acommunication protocol corresponding to data unit 80 (e.g., IP, TCP,UDP, HTTP, SMTP etc.). In some embodiments, such reconstruction mayinclude de-multiplexing network traffic, grouping such traffic accordingto port indicators and/or by network adapter, and re-assembling networkpackets so they can be interpreted in the context of their respectivecommunication protocol. In a step 224, engine 60 determines whetherclient VM 52 is allowed to receive data unit 80 according to the currentsecurity policy in effect on client system 16, and if no, in a step 232engine 60 may block data unit 80, e.g. by dropping unit 80.

When the current security policy allows client VM 52 to receive data, ina step 226, engine 60 performs anti-malware analysis of data unit 80. Insome embodiments, anti-malware analysis comprises detecting malwareand/or malicious behavior related to data unit 80, and may employ anyanti-malware method known in the art. For instance, engine 60 may checka payload of data unit 80 against a reference set of malware-identifyingsignatures (data patterns). Finding a malware-identifyingpattern/signature within the payload may indicate that the datatransmission comprising data unit 80 is malicious, e.g., that therespective data transmission includes a virus or worm. Alternativeanti-malware methods include determining whether data unit 80 ismalformed, or whether data unit 80 does not conform in some other way toa predetermined communication standard. Malformed data transmission maybe an indicator of malicious behavior, since such transmission may causecertain types of errors on the receiving end of the transmission, errorswhich may be exploited for malicious purpose. Other heuristic methodsmay be applied to data unit 80 to determine whether it is indicative ofmalicious behavior. Such heuristics may include statistical analysisand/or identification of temporal usage patterns of a network resourceby client VM 52. For instance, a client VM accessing port 25 (SMTP)multiple times during a short time interval may be suspected of sendingunsolicited communication (spam).

In a step 228, engine 60 determines whether step 226 indicates malwareand/or malicious activity, and if yes, engine 60 proceeds to a step 234described below. When no malware or malicious activity was detected, ina step 230 network introspection engine 60 forwards data unit 80 tohypervisor 40 for transmission to client VM 52, using e.g. the mechanismdescribed above in relation to FIG. 8. When data unit 80 is maliciousand/or client VM is affected by malware as determined by memoryintrospection engine 46, in a step 234 engine 60 stops data unit 80 fromreaching client VM 52. Step 234 may include matching a course of actionto a type of malware/malicious behavior detected in step 226, accordingto the security policy currently in effect on client system 16. Forinstance, for certain types of behavior (e.g., a malformed packet on TCPport 80), the current security policy may instruct engine 60 to allowclient VM 52 to continue to receive network communication from the samesource, while in other instances, such as when data unit 80 comprisesmalware, the current policy may restrict client VM 52 from receiving anycommunication.

In a step 236, network introspection engine 60 may send a security alertto event correlation engine 68, the alert comprising data indicative ofthe security incident identified in step 226 (e.g, data unit 80comprises malware). Event correlation engine 68 may subsequentlyformulate and send a security report 64 related to the incident detectedin step 226 to security server 12.

FIG. 9-B illustrates an exemplary operation of network introspectionengine 60 when sending data from client VM 52 to network(s) 18 a-b. In astep 242, engine 60 receives data unit 80 destined for network(s) 18 a-bfrom client VM 52 via hypervisor 40, e.g. via network driver 72 a ofclient OS 56 and the interrupt injection mechanism described above inrelation to FIG. 8. In a step 244, engine 60 determines whether clientVM 52 is allowed to send data unit 80 according to the current securitypolicy in effect on client system 16, and if no, in a step 252 engine 60may block data unit 80.

When the current security policy allows client VM 52 to send data overthe network, in a step 246, engine 60 performs anti-malware analysis ofdata unit 80, as described above. A step 248 determines whether clientsystem 16 comprises malware and/or performs malicious activity. When nosuch malware/activity is detected, in a step 250 network introspectionengine 60 forwards data unit 80 to network driver 72 b of security OS 58for transmission to network(s) 18 a-b. When data unit 80 is malicious,in a step 254 engine 60 stops data unit 80 from reaching network(s) 18a-b. Next, in a step 254, network introspection engine 60 sends an alertto event correlation engine 68, the alert including data indicative ofthe security incident detected in step 246. Event correlation engine maythen send a security report to security server 12.

The exemplary systems and methods described above allow preventing thespread of malware and/or malicious behavior within a network comprisingmultiple computing systems. An exemplary such network is an enterprisenetwork including a multitude of computing endpoints, such as desktopcomputers and mobile computing and/or telecom devices. In someembodiments of the present invention, each endpoint (client system)operates a hardware virtualization platform, including a client virtualmachine (VM) and a security VM. The security VM executing on each clientsystem is remotely configurable by a central security solution operatingon a server system on the network.

In some embodiments, the security VM is configured to detect malwareand/or malicious activity in network traffic to/from the respectiveclient system, and when such malware or activity is detected, torestrict access of the client system to the network. Such action on thepart of individual security VMs distributed within the network mayeffectively prevent the spread of malicious activity over the networkand/or may prevent leakage of valuable business data by selectivelydisconnecting malicious endpoints from the network.

In some embodiments of the present invention, the client VM may executean off-the-shelf operating system (OS) such as MS Windows®, or MacOS®,thus keeping the setup and administration costs of the enterprisenetwork low. The security VM may employ an open-source OS such asLinux®, customized to perform routing of data traffic to/from the clientVM through the security VM, as described above.

In conventional systems, malware may operate at the same processorprivilege level as other software, including communication modules, andmay therefore interfere in the operation of such software. For instance,in such systems, malware may subvert an attempt to control and/or blocknetwork traffic to/from the respective system. By contrast, in someembodiments of the present invention, a trusted hypervisor operates atroot privilege level on every client system, while all other softwareexecuting on the respective client system (including malware) is removedto lesser privilege levels. In some embodiments, launching the securityVM comprises performing an integrity check of the respective VM. Thesecurity VM is launched only when an image of said VM is found to beidentical to a reference, malware-free image attested by the securityserver.

By giving the security VM exclusive use of a network adapter of theclient system, and by routing all data traffic to/from the clientthrough the security VM, some embodiments of the present invention allowfor an efficient control of malicious network traffic and/or activity.In return, the client VM executing concurrently with the security VM mayhave exclusive use over input and/or output devices of the respectiveclient system. For instance, in some embodiments, only the client VMexposes a user interface. Such a configuration may prevent a user withmalicious intent from displaying a content of the security VM, or frommodifying a content of the security VM from within the client VM.

In conventional network security applications, a firewall may be used torestrict access of a computer system to a network. In such applications,the decision to allow or to block access is typically taken according toa routing indicator, such as a network address of a data packet. Bycontrast, in some embodiments of the present invention, the decisionwhether a data packet is malicious comprises analyzing a content of thepayload of the respective data packet, by e.g., detecting amalware-indicative signature/data pattern within the packet. Suchanalysis may be combined with memory introspection carried out from thelevel of the hypervisor. By scanning the memory of the client VM forindications of malware, some embodiments of the present invention mayincrease the likelihood of detecting malicious behavior, and ofpreventing the spread of malware over the network.

It will be clear to one skilled in the art that the above embodimentsmay be altered in many ways without departing from the scope of theinvention. Accordingly, the scope of the invention should be determinedby the following claims and their legal equivalents.

What is claimed is:
 1. A client system comprising at least one processorconfigured to operate a hypervisor, the hypervisor configured toexecute: a client virtual machine (VM); and a security VM distinct fromthe client VM, the security VM configurable by a centralized securitymanager executing on a remote server connected to the client system by anetwork, wherein the remote server is programmed to configure aplurality of client systems including the client system, wherein thesecurity VM is configured to control a network adapter of the clientsystem according to a security policy received from the remote server,and wherein the security VM is further configured to: receive a dataunit from the network adapter, the data unit comprising a header and apayload, the data unit destined for the client VM, in response toreceiving the data unit, determine whether the data unit is maliciousaccording to a content of the payload, in response, when the data unitis not malicious, transmit the data unit to the hypervisor fortransmission to the client VM, and in response, when the data unit ismalicious, send a security report to the remote server, the securityreport indicative of the maliciousness of the data unit, and restrictaccess of the client VM to the network adapter according to the securitypolicy, wherein the hypervisor is further configured, in response toreceiving the data unit from the security VM, to transmit the data unitto the client VM, and wherein the hypervisor comprises a memoryintrospection engine configured to: determine whether the client VMcomprises malware according to a content of a section of memory of theclient VM, and in response, when the client VM comprises malware, send asecurity alert to the security VM.
 2. The client system of claim 1,wherein the security VM is further configured, in response to thehypervisor sending the security alert, to restrict access of the clientVM to the network adapter.
 3. The client system of claim 1, wherein thesecurity policy is determined according to the security report.
 4. Theclient system of claim 1, wherein the security VM is further configuredto: receive a second security policy from the remote server, the secondsecurity policy instructing the security VM to restrict network accessof the client VM to a second client system of the plurality of clientsystems, and in response, restrict network access of the client VM tothe second client system according to the second security policy.
 5. Theclient system of claim 1, wherein the hypervisor is further configuredto: intercept an attempt of the client VM to send a second data unit tothe network adapter, the second data unit comprising a second header anda second payload, and in response to intercepting the attempt, transmitthe second data unit to the security VM, and wherein the security VM isfurther configured, in response to receiving the second data unit, to:determine whether the second data unit is malicious according to acontent of the second payload, and in response, when the second dataunit is not malicious, transmit the second data unit to the networkadapter.
 6. The client system of claim 1, wherein the client VMcomprises a security agent, the agent configured to receive from thehypervisor a report indicating whether the client VM comprises malware,and in response, to display a content of the report on an output deviceof the client system.
 7. A server system comprising at least oneprocessor programmed to remotely configure a plurality of clientsystems, wherein configuring a client system of the plurality of theclient systems comprises sending a security policy to the client system,and wherein the client system comprises at least one processorconfigured to operate a hypervisor, the hypervisor configured toexecute: a client virtual machine (VM); and a security VM distinct fromthe client VM, the security VM configured to control a network adapterof the client system, and further configured to: receive a data unitfrom the network adapter, the data unit comprising a header and apayload, the data unit destined for the client VM, in response toreceiving the data unit, determine whether the data unit is maliciousaccording to a content of the payload, in response, when the data unitis not malicious, transmit the data unit to the hypervisor fortransmission to the client VM, and in response, when the data unit ismalicious, send a security report to the server system, the securityreport indicative of the maliciousness of the data unit, and in responseto receiving the security policy, restrict access of the client VM tothe network adapter according to the security policy, wherein thehypervisor is further configured, in response to receiving the data unitfrom the security VM, to transmit the data unit to the client VM, andwherein the hypervisor comprises a memory introspection engineconfigured to: determine whether the client VM comprises malwareaccording to a content of a section of memory of the client VM, and inresponse, when the client VM comprises malware, send a security alert tothe security VM.
 8. The server system of claim 7, further configured to:perform an attestation of the client system; and determine the securitypolicy according to a result of the attestation.
 9. The server system ofclaim 7, further configured to determine the security policy accordingto the security report received from the client system.
 10. The serversystem of claim 7, further configured to: in response to receiving thesecurity report from the client system, retrieve a software update froma remote software distribution server; and in response, transmit theupdate to the client system over the network.
 11. The server system ofclaim 7, further configured, in response to receiving the securityreport from the client system, to send a second security policy to asecond client system of the plurality of client systems, the secondsecurity policy restricting network access of the second client systemto the client system.
 12. The server system of claim 7, furtherconfigured, in response to receiving the security report from the clientsystem, to send an electronic message to a system administrator, theelectronic message determined according to the security report.
 13. Theserver system of claim 7, wherein the security VM is further configured,in response to the hypervisor sending the security alert, to restrictaccess of the client VM to the network adapter.
 14. The server system ofclaim 7, wherein the security VM is further configured to: receive asecond security policy from the remote server, the second securitypolicy indicating that a second client system of the plurality of clientsystems is malicious, and in response, restrict access of the client VMto the second client system according to the second security policy. 15.The server system of claim 7, wherein the hypervisor is furtherconfigured to: intercept an attempt of the client VM to send a seconddata unit to the network adapter, the second data unit comprising asecond header and a second payload, and in response to intercepting theattempt, transmit the second data unit to the security VM, and whereinthe security VM is further configured, in response to receiving thesecond data unit, to: determine whether the second data unit ismalicious according to a content of the second payload, and in response,when the second data unit is not malicious, transmit the second dataunit to the network adapter.
 16. The server system of claim 7, whereinthe client VM comprises a security agent, the agent configured toreceive from the hypervisor a report indicating whether the client VMcomprises malware, and in response, to display a content of the reporton an output device of the client system.
 17. A method comprisingemploying at least one processor of a client system to form a hypervisorconfigured to expose: a client virtual machine (VM); and a security VMdistinct from the client VM, the security VM configured to control anetwork adapter of the client system, the security VM configurable by acentralized security manager executing on a remote server connected tothe client system by a network, wherein the remote server is programmedto configure a plurality of client systems including the client system,and wherein configuring the client system comprises the remote serversending a security policy to the client system; wherein the methodfurther comprises: employing the security VM to receive a data unit fromthe network adapter, the data unit comprising a header and a payload,the data unit destined for the client VM, employing the security VM, inresponse to receiving the data unit, to determine whether the data unitis malicious according to a content of the payload, and in response,when the data unit is not malicious, to transmit the data unit to thehypervisor for transmission to the client VM, and when the data unit ismalicious, to send a security report to the remote server, the securityreport indicative of the maliciousness of the data unit, and to restrictaccess of the client VM to the network adapter according to the securitypolicy, and wherein the method further comprises employing thehypervisor, in response to receiving the data unit from the security VM,to transmit the data unit to the client VM, wherein the hypervisorfurther comprises a memory introspection engine configured to: determinewhether the client VM comprises malware according to a content of asection of memory of the client VM, and in response, when the client VMcomprises malware, send a security alert to the security VM.
 18. Amethod comprising: employing at least one processor of a server systemto remotely configure a plurality of client systems connected to theserver system by a network, wherein configuring a client system of theplurality of client systems comprises sending a security policy to theclient system; and in response to configuring the plurality of clientsystems, employing at least one processor of the server system toreceive a security report from the client system, wherein the clientsystem comprises a hypervisor configured to execute: a client virtualmachine (VM); and a security VM distinct from the client VM, thesecurity VM configured to control a network adapter of the client systemand further configured to: receive a data unit from the network adapter,the data unit comprising a header and a payload, the data unit destinedfor the client VM, in response to receiving the data unit, determinewhether the data unit is malicious according to a content of thepayload, in response, when the data unit is not malicious, transmit thedata unit to the hypervisor for transmission to the client VM, and inresponse, when the data unit is malicious, send the security report tothe server system, the security report indicative of the maliciousnessof the data unit, and restrict access of the client VM to the networkadapter according to the security policy, wherein the hypervisor isfurther configured, in response to receiving the data unit from thesecurity VM, to transmit the data unit to the client VM, and wherein thehypervisor comprises a memory introspection engine configured to:determine whether the client VM comprises malware according to a contentof a section of memory of the client VM, and in response, when theclient VM comprises malware, send a security alert to the security VM.